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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the stage 2 description (architectural solution and functionalities) for the Presence 
Service, which includes the elements necessary to realise the stage 1 requirements in TS 22.141 [2]. 

The present document includes information applicable to network operators, service providers and manufacturers. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 22.141: "Presence service; Stage 1". 

[3] IETF RFC 3863: "Presence Information Data Format", August 2004. 

[4] IETF RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)", August 

2004. 

[5] 3 GPP TS 33.203: "3G security; Access security for IP-based services". 

[6] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 

architecture and principles". 

[7] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 

Subsystem (IMS) charging". 

[8] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security". 

[9] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[10] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2". 

[II] IETF RFC 3265 : " Session Initiation Protocol (SIP) Event Notification" . 

[12] Void. 

[13] 3GPP TS 29.061 : "Interworking between the PubHc Land Mobile Network (PLMN) supporting 

Packet Based services and Packet Data Networks (PDN)". 

[14] 3GPP TS 23.271: "Location Services (LCS); Functional description; Stage 2". 

[15] 3GPP TS 23.198: "Open Service Access (OSA); Stage 2". 

[16] IETF RFC 2778: "A Model for Presence and Instant Messaging". 

[17] IETF RFC 2779: "Instant Messaging / Presence Protocol Requirements". 

[18] 3GPP TS 23.002: "Network architecture". 

[19] 3GPP TS 23.234: "3GPP system to Wireless Local Area Network (WLAN) interworking; System 

description" . 
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[20] LIF TS 101: "Mobile Location Protocol Specification" (Location Interoperability Forum 2001) 

[Available at http://www.openmobilealliance.org]. 

[21] 3GPP TR 23.981 "Interworking aspects and migration scenarios for IPv4 based IMS 

implementations" . 

[22] 3GPP2 X.S0027-004: "Network Presence". 

[23] 3GPP2 X.S0004: "Introduction to MAP". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in TR 21.905 [1] and TS 22.141 [2] and the 
following apply: 

Presence List Server: functional entity that stores grouped lists of watched presentities and enables a Watcher 
Application to subscribe to the presence of multiple presentities using a single transaction. 

Presence Network Agent: network located element that collects and sends network related presence information on 
behalf of the presentity to a presence server. 

Presentity Presence Proxy: functional entity that provides presentity related functionality such as determining the 
presence server associated with a presentity. 

Presence Server: network entity responsible for managing presence information on behalf of a presence entity. 

Presence User Agent: a terminal or network located element that collects and sends user related presence information 
to a presence server on behalf of a Principal. 

Watcher Presence Proxy: a functional entity that provides watcher related function such as authentication of watchers. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations in TR 21.905 [1] and TS 22.141 [2] and the following 
apply: 

AAA Authentication, Authorisation and Accounting 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CAP CAMEL Application Part 

CGI Cell Global Identity 

CS Circuit Switched 

CSCF Call Session Control Function 

GGSN Gateway GPRS Support Node 

GMLC Gateway Mobile Location Centre 

GPRS General Packet Radio Service 

HLR Home Location Register 

HSS Home Subscriber Server 

HTTP Hyper Text Transport Protocol 

I-CSCF Interrogating CSCF 

IETF Internet Engineering Task Force 

IMS IP Multimedia Subsystem 

ISDN Integrated Service Digital Network 

LIF Location Interoperability Forum 

MAP Mobile Application Part 

MSC Mobile Switching Centre 

MSISDN Mobile Subscriber ISDN Number 

P-CSCF Proxy CSCF 

PDG Packet Data Gateway 



ETSI 



3GPP TS 23.141 version 10.0.0 Release 10 



ETSI TS 123 141 VI 0.0.0 (2011-03) 



PLMN Public Land Mobile Network 

PS Packet Switched 

PUA Presence User Agent 

RFC Request For Comments 

SAI Service Area Identity 

S-CSCF Serving CSCF 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SMS Short Message Service 

UE User Equipment 

URL Uniform Resource Locator 

WAP Wireless Access Protocol 

WLAN Wireless Local Area Network 

WML Wireless Markup Language 

WV Wireless Village 



Presence Architecture 



4.1 



Overview 



The Presence Service provides the ability for the home network to manage presence information of a user's device, 
service or service media even whilst roaming. A user's presence information may be obtained through input from the 
user, information supplied by network entities or information supplied by elements external to the home network. 
Consumers of presence information, watchers, may be internal or external to the home network. 



4.2 



Reference Architecture Model 



The generic reference architectural model for providing presence service is depicted in Figure 4.2-1 below. The details 
of the elements in the figure (e.g. agents, proxies) are provided in clause 5. 

The mapping of the Presence Service functional elements and reference points to the functional elements and reference 
points in the 3GPP Network Architecture TS 23.002 [18] (and additionally IMS) is defined in clauses 4.3 and clause 5. 
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Presence suppliers 



Presence External agent (Presence 

information provided by elements 

outside the provider' s network) 



Watcher 
applications 



Pex 



Pw 



Presence User agent 
(Presence information 
provided by the user) 



Pep 



Peu 



Pr- 



Presence Network agent (Presence 
information provided by the 
network) 



Pp — 



J3GPPAAA 

Server 



Ph— 



PDG 



Pi- 



HSS/HLR 



Pc— 



S-CSCF 



Pg 



MSC Servel- 



Pen 



Pk- 



SGSN 



Pl- 



GGSN 



GMLC 
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Presence 
List Server 



Watcher 
Presence Proxy 



Pw- 



Pw 



Presentity 
Presence Proxy 



Pwp 



Px 



HSS 
(HLR) 



Presence server 
(home network) 



Interfaces Ph, Pi, Pc, Pg, Pk and PI are based on existing Release 5 
procedures e.g. CAMEL, MAP, CAP, RADIUS, ISC, Cx, Sh. 
The Pr, Pp interfaces are based on existing Release 6 procedures of 
the 3 GPP- WLAN interworking architecture. 

Figure 4.2-1 : Reference architecture to support a presence service 

4.3 Reference points 

4.3.1 Reference point Presence User Agent - Presence Server (Peu) 

This reference point shall allow the Presence User Agent to manage subscription authorization policies. 

IPv6 shall be supported for all functionalities required from a Presence User Agent that supports the Peu reference 
point. An IPv6 capable 3GPP UE shall use IPv6 when accessing Peu. However, early IMS implementations and 
deployments may use IPv4;if IPv4 is used, the guidelines and recommendations in TR 23.981 [21] should be followed. 

This reference point uses capabilities defined for the Ut reference point as defined in TS 23.002 [18]. 

4.3.2 Reference point Presence Network Agent - Presence Server (Pen) 

This reference point shall allow a presentity' s presence information to be supplied to the Presence Server. The transport 
on this reference point shall not impose any limitations to the size of the presence information. 

Pen shall provide mechanisms for the Network Agent to manage subscription authorisation policies. 

Pen shall provide mechanisms for the Network Agent to supply or update only a certain subset of the presentity's 
presence information to the Presence Server. 

Pen shall provide mechanisms for activating or deactivating the reporting of Presence Information for a given presentity 
from the network entities within the PLMN. 

The Pen interface is an intra-operator interface. In order to provide the all the functionalities required on this reference 
point, a combination of multiple protocols may be used. In general the protocols used at the Pen reference point are not 
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standardised. However, for 3GPP2 systems this reference point is defined in X.S0027-004 [x]. At least, this interface 
shall support the transport of presence information under the PIDF format as specified in IETF RFC 3863 [3]. 

4.3.3 Reference point Presence External Agent - Presence Server (Pex) 

This reference point shall allow a presentity's presence information to be supplied to the Presence Server. The transport 
on this reference point shall not impose any limitations on the size of the presence information. 

Pex shall provide mechanisms for the Presence External Agent to supply or update only a certain subset of the 
presentity's presence information to the Presence Server. 

In order to provide all the functionalities required on this reference point, a combination of multiple protocols may be 
used. Presence information obtained from an external network by the Presence External Agent is transferred across the 
Pex reference point to the Presence Server. This interface shall support the transport of presence information under the 
PIDF format as specified in IETF RFC 3863 [3]. 

4.3.4 Reference point Watcher applications - Presentity Presence Proxy 
(Pw) 

This reference point shall allow a Watcher application to request and obtain presence information. This interface shall 
support the transport of presence information under the PIDF format as specified in IETF RFC 3863 [3]. 

The transport shall not impose any limitations to the size of the presence information. 

In order to provide all the functionalities required on this interface, a combination of multiple protocols may be used. 

This reference point shall support both presence monitoring and fetching modes. In the fetching mode, it shall be 
possible for the watcher to once request all or only a subset of a presentity's presence information (e.g. one or more 
tuples). The subset of the presence information is defined by the filter that is carried in the presence information 
subscription. 

In the monitoring mode, it shall be possible for the watcher to request monitoring of all or a subset of a presentity's 
presence information (i.e. one or more tuples) . Watcher shall be able to explicitly indicate the capability to process 
partial updates. The subset of the presence information is defined by the filter that is carried in the presence information 
subscription. It shall be possible for the watcher to request the presence server to filter out information when the 
watcher is equal to the publishing Presence User Agent. 

It shall be possible for the notifications containing the presentity's presence information to contain only information as 
defined by filters. It shall be possible for the notifications containing the presentity's presence information to contain 
only the modified tuples, i.e. only those tuples which have changed since the last notification. 

This reference point may allow a Watcher application to use presence lists in presence information subscriptions, and 
the Watcher Presence Proxy to interface to a server that provides the functionality of Presence List Server. 

IPv6 shall be supported for all functionalities required from a Watcher application that supports the Pw reference point. 
An IPv6 capable 3GPP UE shall use IPv6 when accessing Pw. However, early IMS implementations and deployments 
may use IPv4; if IPv4 is used, the guidelines and recommendations in TR 23.981 [21] should be followed. 

4.3.5 Reference point HSS/HLR - Presence Network Agent (Ph) 

This reference point shall allow the Presence Network Agent to query HSS/HLR about the state and status of a 
subscriber (associated with a presentity) from the serving network (for 3 GPP this is the CS domain or GPRS) and IMS 
perspective. 

This reference point permits the Presence Network Agent to activate and deactivate the reporting of mobility 
management events from the serving network (for 3GPP this is the CS domain or GPRS) and/or the IMS -specific 
reports from the S-CSCF. 

This reference point uses capabilities defined for the Sh reference point as defined in TS 23.002 [18] as well as the 
MAP interface. 
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4.3.6 Reference point S-CSCF - Presence Network Agent (Pi) 

The S-CSCF may provide IMS -specific presence information (e.g. about IMS registration state). This reference point 
shall use mechanisms defined for the ISC reference point as defined in TS 23.002 [18]. 

4.3.7 Reference point Presentity Presence Proxy - HSS (Px) 

The Px interface is an intra-operator interface. This interface shall assist locating the Presence Server of the presentity. 
This interface is implemented using the mechanisms defined for the Cx and Dx reference points as defined in 
TS 23.002 [18]. 

4.3.8 Reference point Presence Network Agent - GMLC (PI) 

This reference point shall be used by the Presence Network Agent to retrieve location information related to a 
subscriber (associated with the presentity). This reference point is the interface to GMLC and it is an instance of the Le 
reference point (defined in TS 23.271 [14] and TS 23.002 [18]). In the case of Presence the LCS client (defined in 
TS 23.271 [14]) is the Presence Network Agent and so the protocol implementing PI needs to be defined. Though 
normally a stage 3 responsibility in this case the protocol to be used is defined here since it is a reference to an existing 
protocol. Thus, PI shall conform to OMA's LIF-MLP specification [20]. 

For 3GPP2 systems, the interface for this reference point is to the 3GPP2 Position Server and is not supported in the 
current release of the specification. 

4.3.9 Reference point Presence Network Agent - SGSN (Pg) 

This reference point shall allow the SGSN to report mobility management related events (such as attach/not reachable 
for paging/detach/routing area update) to the Presence Network Agent. 

This reference point may allow the SGSN to report Mobility States (such as Detached, Idle and Connected) and Session 
States (such as PDP context active and inactive). 

This reference point is implemented using the existing mechanisms of CAMEL phase 4, 3GPP Release 5. 

For 3GPP2 systems, this reference point is not supported. 

4.3.10 Reference point Presence Network Agent -MSC Server/VLR (Pc) 

This reference point shall allow the MSC ServerA^LR to report the mobility management related events to the Network 
Agent (such as attach/detach/location area update) and may allow the MSC Server/VLR to report call related events 
(such as call setup with the bearer information and call release). 

This reference point may allow the MSC Server/ VLR to report Mobility States (such as Detached, Idle and Connected) 
and Call States (such as Busy with Bearer information and Idle). 

This reference point is implemented using the existing mechanisms of CAMEL phase 4, 3GPP Release 5. 

For 3GPP2 systems, the interface to this reference point is defined in 3GPP2 X.S0004 [23]. 

4.3.1 1 Reference point Presence Network Agent - GGSN (Pk) 

This reference point shall allow the GGSN to report presence relevant events to the Presence Network Agent (such as 
PDP context activation/de-activation). This reference point is implemented using the mechanisms of the RADIUS 
interface for reporting of access requests on Gi reference point as defined in TS 29.061 [13]. 

For 3GPP2 systems, this reference point is not supported. 
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4.3.12 Reference point Presence Network Agent - 3GPP AAA Server (Pr) 

This reference point shall allow the 3 GPP AAA Server to report IP-connectivity related events to the Presence Network 
Agent (such as WLAN UE attaching/detaching and tunnel establishment/removal). The Pr reference point shall be as 
much as possible based on mechanisms of existing interfaces. 

For 3GPP2 systems, the interface for this reference point is to the AAA server and is defined in X.S0027-004 [22]. 

4.3.13 Reference point Presence Network Agent - PDG (Pp) 

This reference point shall allow the PDG to report presence relevant events to the Presence Network Agent (such as 
tunnel establishment/removal, allocation of the remote IP address for the WLAN UE). This reference point is based on 
reusing of the Wi reference point. 

For 3GPP2 systems, this reference point is not supported. 

4.3.14 Reference point Presence User Agent - Presentity Presence Proxy 
(Pep) 

This reference point shall allow a presentity' s presence information to be supplied to the Presence Server. The transport 
on this reference point shall not impose any limitations on the size of the presence information. This interface shall 
support the transport of presence information under the PIDF format as specified in IETF RFC 3863 [3]. 

Pep shall provide mechanisms for the Presence User Agent to obtain information on watcher subscriptions to the 
presentity's presence information. 

Pep shall provide mechanisms for the Presence User Agent to supply or update only a certain subset of the presentity's 
presence information to the Presence Server. It shall also be possible for the Presence User Agent to supply the 
complete presence document over Pep. 

Pep shall support SIP-based communications for publishing presence information. 

IPv6 shall be supported for all functionalities required from a Presence User Agent that supports the Pep reference 
point. An IPv6 capable 3 GPP UE shall use IPv6 when accessing Pep. However, early IMS implementations and 
deployments may use IPv4; if IPv4 is used, the guidelines and recommendations in TR 23.981 [21] should be followed. 

4.3.15 Reference point Presentity Presence Proxy - Presence Server 
(Pwp) 

The Pwp interface is an intra-operator interface. This reference point shall allow all the functionalities provided by the 
Pw and Pep reference points. 

4.3.16 Reference point Watcher Applications - Presence List Server (Pet) 

This reference point shall allow a Watcher application to manage presence list information in the Presence List Server. 
This reference point uses capabilities defined for the Ut reference point as defined in TS 23.228 [9]. 

4.4 Support of OSA Presence Service Capability Server in the 
Presence Architecture 

An OSA API may be provided to allow external application to access presence service features, details of which are 
found in TS 23.198 [15]. 

The OSA Presence SCS may act like a presentity or a watcher. The application may then register as a presentity and/or 
watcher, to supply presence information, to request presence information, to be notified of subsequent changes, to 
request watcher information, and to manage subscription authorisation policies. 
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5 Functional Entities To Support Presence Service 

5.1 Presence Server 

The Presence Server shall reside in the presentity's home network. 

The Presence Server shall be able to receive and manage presence information that is published by the Presence 
User/Network/Extemal agents, and shall be responsible for composing the presence-related information for a certain 
presentity from the information it receives from multiple sources into a single presence document. The composing 
process to create the single presence document may involve complex transformations of presence information such as 
modifying the presence information from one presence source based on information from another presence source. In 
particular, the Presence server shall be able to receive and manage presence information that is published from multiple 
Presence User agents of the same presentity. The Presence Server shall be able to process partial publications of 
information from Presence User Agents. These partial publications contain the presence information of the presentity 
that has been modified since the latest publication sent to the Presence Server about this presentity. 

These Presence User agents may be updating the same parts of the presence information. 

The mechanisms for combining the presence related information shall be defined based on presence attributes, and 
according to certain policy defined in the Presence Server. The Presence Server shall be capable of receiving and 
composing the Presence information received in the standardized formats from authorized sources regardless of the 
source of the information or the ability to interpret the information contained in the presence tuples. The information 
that the Presence Server is not able to interpret shall be handled in a transparent manner. 

The Presence Server shall also allow watchers to request and subscribe to either the full set of presence information of a 
presentity, or only certain information within. Watcher defines the subset of the presence information, that he is 
interested in, by the filter that is carried in presence information subscription. The Presence Server shall be able to 
generate partial notifications to a watcher, which has indicated the capability to process them. These partial notifications 
contain the presence information of the presentity that has been modified since the latest notification sent to the watcher 
about this presentity, and required additional information to be able to link the partial notification to the information 
watcher has received earlier. In case the watcher does not indicate the capability to process partial notifications the 
presence server shall send only full updates. 

Before the subscription to presence information is accepted, the Presence Server should attempt to verify the identity of 
the watcher that subscribes to Presentity's Presence information, except if the watcher has indicated his desire to remain 
anonymous. The action taken by the Presence Server if the verification fails may include notifying the Presentity. 

The Presence Server shall support SIP-based communications for publishing presence information. 

The Presence Server shall support SIP-based communications with the Presentity Presence Proxy. The Presence Server 
is a SIP Application Server as defined by TS 23.228 [9], and is located using SIP URLs, standard SIP and existing IMS 
mechanisms (SIP routing, HSS query, ISC filtering, etc.). 

The Presence Server shall provide Subscription Authorization Policy. The Subscription Authorization Policy determines 
which Watchers are allowed to subscribe to a Presentity's Presence information. 

The Subscription Authorization Policy also determines which tuples of the Presentity's Presence information the 
watcher has access. It shall be possible for the Presentity's Presence User Agent to provide the Subscription 
Authorization Policy or it may be configured by the operator as part of the service provisioning. 

The Presence Server may provide a watcher configurable filtering function that is used to limit the information that is 
delivered to a watcher. After subscription the authorized watchers get notified of the actual Presence Information based 
on the Subscription Authorization Policy and the filters set by the watcher in the subscription. If the Presence Server 
does not support the filters as requested by the watcher, this is indicated to the watcher. In this case the notification shall 
contain the actual Presence information based on the Subscription Authorization Policy and local policy in the Presence 
Server. The Presence Server may support one or more of the following types of filters: Filters, which allow watchers to 
define: 

- the tuples that the watcher is interested in; 

Watcher can define a criteria which allows the complete tuple and all the information within the tuple to be 
transmitted. E.g. watcher can define the filter to permit notifying all the tuples (and all the information within 
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those tuples) which has "tel:+ 1630555 1212" as the contact address or "Instant Messaging" as a communication 
means. 

- the attributes that the watcher is interested in; and 

Watcher can define a criteria which result notifies to contain values only for defined attributes (attributes are 
defined by the filter and values for other attributes are not available in the notifications) 

- the triggers when a notification should be sent. 

Watcher can define a criteria which specifies when to send a notification. E.g. every time the communication 
means status attribute changes its value, a notification is sent to the watcher. Another example: filter out and do 
not send the notifications resulting from the publication of the Presence User agent that is equal to the watcher. 

The Presence Server shall collect watcher information to enable presentity to obtain information of the watchers that are 
or have been requesting, fetching or subscribing presentity's presence information. Service provider shall be able to 
define the maximum time period over which information is collected and stored. The watcher information list shall 
include: 

- identity of the watcher (unless anonymity was requested); 

In case of anonymous watcher, the identity of the watcher shall not be provided to the presentity. The presentity 
shall be able to determine that an anonymous watcher has requested, fetched or subscribed presence information 
of the presentity including related information as specified in this list without revealing the watchers identity. 

- time of the request, fetch or subscription; 

- length of the subscription; and 

- state of the request or subscription. 

The Presence Server shall be able to support the presentity obtaining the above watcher information. The Presence 
Server shall be able to receive watcher information fetches and subscriptions from the presentity. These watcher 
information fetch and subscribe requests shall be able to contain filters which define: 

- what watchers the presentity is interested in; 

Possible categories are: 

- all watchers; 

- defined watchers; 

- new, unauthorised watchers; and 

- defined and new, unauthorised watchers. 

- what information the presentity is interested in; and 

The information is all or part of the watcher information list as defined above. 

the length of the watcher information history collection period that the presentity is interested in. 

In response to watcher information fetches, the presence server shall be able to provide requested watcher information 
to the presentity. In response to watcher information subscriptions, the presence server shall provide notification to the 
presentity of the current state of the subscribed watcher information. When there are subsequent changes in the 
subscribed watcher information, notifications of the changes in watcher information are sent to the presentity. 

The Presence Server may support rate-limiting or filtering of the presence notifications based on local policy in order to 
minimize network load. 



5.2 Presence Agent Elements 



The Agent elements in the Presence Architecture are functionally distinct from the Presence Server functional element. 
The generic function of the Agent elements is to make presence information available to the Presence Server element in 
standardized formats across standardized interfaces. 

5.2.1 Presence User Agent 

The Presence User Agent element shall provide the following functionality: 
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- The Presence User Agent shall collect Presence information associated with a Presentity representing a Principal. 

The Presence User Agent shall assemble the Presence information in the format defined for the Peu and Pep 
reference points. 

- The Presence User Agent shall send the Presence information to the Presence Server element either via the 
Presentity Presence Proxy over the Pep reference point or over the Peu reference point.- The Presence User 
Agent shall be capable of managing the subscription authorisation policies. 

- The Presence User Agent shall handle any necessary interworking required to support terminals that do not 
support the Peu and Pep reference points. 

Presence User Agent shall uniquely identify itself (among the Presence User Agents of the presentity) when 
publishing presence information. 

From a conceptual view, the Presence User Agent (PUA) element resides between the presence server and the user's 
equipment as illustrated in the reference architecture in figure 4.2-1. In reality, a Presence User Agent may be located in 
the user's terminal or within a network entity. 

Where the PUA is located in UE, the UE shall support Pep and the Peu reference point to the Presence Server as 
illustrated in Figure 5.2.1-1 below. 
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Figure 5.2.1-1 : UE based Presence User Agent 

The Network based Presence User Agent shall reside in the presentity' s home network. 

Where the PUA is located within the network, the particular network entity shall support the Pep and Peu reference 
point to the presence server as illustrated in Figure 5.2.1-2.. In this case, additional functionality may be required to 
provide routeing between UE and the Presence User Agent, and, for the Presence User Agent to "register" the user 
within the "Presence network". 

In this case, the interface between the terminal and the Presence User agent is outside of the scope of the present 
document. 
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5.2.1.1 



Figure 5.2.1-2: Network based Presence User Agent 



Relationship of Presence User Agent with IMS entities 



When the Presence User Agent is located in an IMS UE the Pep reference point is implemented using the Gm, Mw and 
ISC reference points as defined in TS 23.002 [18]. 
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The Gm, Mw, and ISC reference points allow a presentity's presence information to be supplied to the Presence 
Server. These reference points also allow for the Presence User Agent to obtain information on watcher 
subscriptions to the Presentities Presence Information. 

The Peu reference point is implemented using the Ut reference point as defined in TS 23.002 [18]. The Ut 
reference point provides mechanisms for the Presence User Agent to manage subscription authorisation policies. 
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Figure 5.2.1-3: Presence User Agent in IMS architecture 

5.2.2 Presence Network Agent 

5.2.2.0 General 

The Presence Network Agent shall reside in the presentity's home network. 

5.2.2.1 Functions of the Presence Network Agent 

The Presence Network Agent element shall provide the following functionality: 

- The Presence Network Agent shall receive Presence information from network elements within the HPLMN and 
VPLMN. 

- The Presence Network Agent shall be able to send requests to the HSS/HLR to cause other network elements to 
send (or stop sending) Presence Information to the Presence Network Agent. Note that this only applies where 
the other network element has Presence Information subscriptions managed via the HSS/HLR. 

- The Presence Network Agent shall associate Presence information with the appropriate Subscriber/Presentity 
combination. 

- The Presence Network Agent shall convert the Presence information into the format standardized for the Pen 
interface. 

- The Presence Network Agent shall publish the Presence information to the Presence Server across the Pen 
reference point. 
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5.2.2.2 



Suppliers of Presence Information 



The Presence Network Agent may receive Presence information from one or more of the following 2G/3G network 
elements over the specified reference point: 



Network Element supplying Presence 
Information 


Reference Point 


HSS/HLR 


Ph 


S-CSCF 


Pi 


MSC Server/VLR 


Pc 


SGSN 


Pg 


GGSN 


Pk 


GMLC 


PI 


3GPP AAA Server 


Pr 


PDG 


Pp 



It is a matter of implementation and operator choice which reference points the Presence Network Agent supports 
towards suppliers of Presence information. Where other reference points support such a capability, a Presence Network 
Agent can use the Ph reference point to activate and deactivate publishing of Presence information via those reference 
points. 



5.2.2.3 



Relationship of Presence Network Agent with IMS entities 



Figure 5.2.2.3-1 below presents the architecture for the S-CSCF and the HSS to provide presence related information to 
the Presence Server. 

NOTE: The architecture on Figure 5.2.2.3-1 is an IMS -specific simplification of some of the interfaces of the 
generic Presence reference architecture presented in clause 4. 
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Figure 5.2.2.3-1 : IMS network elements supplying presence information 

The ISC interface is used to convey presence information from the S-CSCF to the Presence Network Agent. More 
specifically, the functions of the Pi interface are taken care of by the ISC interface. As an example, the S-CSCF can 
convey a user's IMS -registration status by generating and sending a 3^^ party REGISTER request to the Presence server. 

The Sh interface is used to convey information from the HSS to the Presence Network Agent. More specifically, the 
functions of the Ph interface are taken care of by the Sh interface. 

Since the Network Agent is introduced as a functional entity, which models the abstraction from the different presence 
sources, the network agent and the presence server may be collocated. In case of an IMS-only network environment the 
Pen reference point is assumed to be realized by an internal interface. 
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5.2.3 Presence External Agent 

The Presence External Agent element shall provides the following functionality: 

- The Presence External Agent shall supply Presence information from external networks; 

The Presence External Agent shall send the Presence information across the Pex reference point according to the 
format standardized for the Pex reference point; 

- The Presence External Agent shall handle the interworking and security issues involved in interfacing to external 
networks; 

- The Presence External Agent shall have functionality to resolve the location of the Presence Server associated 
with the Presentity. 

Examples of Presence Information that the Presence External Agent may supply, include: 

- Third party services (e.g. calendar applications, corporate systems); 
Internet Presence Services; 

- Other Presence Services. 

Editor's Note: The mapping of Pex to IMS reference points is FES. 

5.3 Presence Proxies 

5.3.1 Presence Proxies introduction 

In order to support a presence service, in particular across PLMN borders, generic network functions are needed, e.g. 
routing and security. The presence proxies provide these functions. Presence proxies constitute the entry and exit point 
for presence requests between PLMNs. 

5.3.2 Watcher Presence Proxy 

When a Watcher application intends to access some presence information of a presentity, it first needs to contact its 
Watcher Presence Proxy which will contact the Presentity Presence Proxy to find the Presence Server containing this 
information. 

The Watcher Presence Proxy shall provide the following functionality: 

- Address resolution and identification of target networks associated with a presentity; 

- Authentication of watchers; 

- Interworking between presence protocols for watcher requests; 

- Generation of accounting information for watcher requests. 

5.3.3 Presentity Presence Proxy 

The Presentity Presence Proxy shall provide the following functionality: 

- Determination of the identity of the presence server associated with a particular presentity; 
Authentication of Watcher Presence Proxy; 

- Authentication of the Presence user Agent; 

- Generation of accounting information for updates to presence information. 
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5.3.4 Relationship of Presence Proxies with IMS entities 

The functionalities of the Watcher Presence Proxy are then taken care of by the P-CSCF and the S-CSCF: 

- The S-CSCF is responsible for authentication according to procedures described in TS 33.203 [5]. 

- The charging and accounting procedures are conducted as per procedures defined by TS 32.240 [6], 
TS 32.260 [7]. 

- The security mechanisms between the Watcher and the Presentity Presence proxy are defined by TS 33.210 [8]. 

The functionality of the Presentity Presence Proxy is taken care of by the P-CSCF, I-CSCF and the S-CSCF as defined 
in TS 23.228 [9]. 

The procedures for locating, routing to and accessing the Presence Server of the presentity are defined in TS 23.228 [9] 
and TS 23.218 [10]. These procedures also take care of routing and accessing the Presence Server of a presentity that is 
associated with an unregistered UE. 

The functionality of the Watcher Presence Proxy and the Presentity Presence Proxy are allocated to the functional 
element CSCF as defined in TS 23.002 [18]. 

Figure 5.3.4-1 below presents the mapping of the Watcher and Presentity Presence Proxy functionalities to IMS 
network elements when located within the IMS along with the Watcher application. This mapping is based on and 
restricted to reusing the existing IMS architecture mechanisms and can be clearly seen in the detailed information flows 
show in annex A. 
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Figure 5.3.4-1 : Both the Watcher application and the Presence Server located within IMS 

NOTE: The standard IMS (SIP) routing mechanisms define whether a certain CSCF is indeed included in the path 
of a SUBSCRIBE or NOTIFY transaction. 
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As described in IETF RFC 3856 [4], the Watcher AppHcation sends a SIP SUBSCRIBE to Event: presence addressed to 
the presentity 's SIP URL to subscribe or fetch presentity 's presence information. This SUBSCRIBE transaction will be 
routed and handled by the IMS infrastructure according to standard IMS routing and ISC procedures defined in 
TS 23.228 [9] andTS 23.218 [10]. 

The Presentity's S-CSCF is not mandated to insert itself into the Record-Route header of the initial SUBSCRIBE 
request, in case the S-CSCF does not execute any functions for the subsequent requests and responses of the dialog. 

The presence document will be provided from the Presence Server to the Watcher Application using SIP NOTIFY 
along the dialogue setup by SUBSCRIBE either within the NOTIFY payload, or via a URL provided in the NOTIFY. 
The means to fetch the content can be seen as part of the Pw interface. 

5.4 Watcher Applications 

5.4.1 Communication between Watcher and Presentity Proxy 

Communications between the Presentity Presence Proxy and the Watcher Presence Proxy shall be based on SIP as 
shown in figure 5.4.1-1 below. Other IP-based mechanisms may also be needed to support the delivery of large amount 
of presence information. Support for non-SIP based Watchers may be provided by the use of an interworking functions 
co-located with the Watcher Presence Proxy. In this case the Watcher Presence Proxy interworking function needs to be 
able to support routing to the non-SIP based watcher. 
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Figure 5.4.1-1 : Communications between the Presentity Presence Proxy and the Watcher Presence 

Proxy for Watchers 

5.4.2 Watcher application in an IMS UE 

The Watcher appHcation can be located within a UE registered in the IMS network, it is registered to a S-CSCF via a P- 
CSCF according to standard IMS procedures as specified in TS 23.228 [9]. 

Watcher appHcation shall be able to handle full and partial notifications. The capability to process partial notifications 
shall be indicated to the presence server when making a presence subscription. 

The Pet reference point is implemented using the Ut reference point. 

5.4.3 Network based Watcher Application Server 

The Watcher application can be located within an Application Server behind the ISC reference point. This entity is the 
Network Based Watcher Application Server. 

Watcher application shall be able to handle full and partial notifications. The capability to process partial notifications 
shall be indicated to the presence server when making a presence subscription. 

5.4.4 Watcher application located in the external Internet 

If a Watcher application is located in the external Internet, then the Watcher Presence Proxy shall reside in a network 
capable of executing security functionalities as per procedures defined in TS 33.210 [8]. 

The interworking with Watcher Applications located in the external Internet not supporting the standard Pw reference 
point is out of the scope of the present document. 
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5.4.5 Presence Server located in the external Internet, Watcher 
application located in the IMS 

If a Watcher Application is located in the IMS, the functionalities of the Watcher Presence Proxy shall be as described 
in clause 5.3.2. Depending on the mechanisms and protocols supported by the external Presence Server, the Watcher 
Presence Proxy may implement additional functionalities, e.g. protocol mapping. 

The interworking with Presence Servers located in the external Internet not supporting the standard Pw reference point 
is out of the scope of the present document. 

5.5 Presence List Server 

The Presence List Server stores grouped lists of watched presentities and enables a Watcher Application to subscribe to 
the presence of multiple presentities using a single SUBSCRIBE transaction. Presence List Server also stores and 
enables the management of filters associated to presentities in the presence list. Presence list server shall attach 
associated filter to each individual SUBSCRIBE transaction. The Presence List Server is implemented as a SIP 
Application Server function as defined in TS 23.228 [9]. For the case where the Watcher Application resides in an IMS 
UE, the Presence List Server may support the Ut reference point to allow the user to manage his presence lists. 



6 Presence attributes 

6.1 Presence Attributes 

Presence attributes describe the presentity. As the type of the presentity can vary significantly the definition of generic 
attributes is practically impossible. Attributes can be defined by the service providers and manufacturers as part of the 
other presence markup as specified in IETF (e.g. RFC 2778 [16], RFC 2779 [17]). The values (and process of 
generating them) and value ranges for all attributes shall be kept relatively simple. It is necessary for the 3GPP 
subscriber to understand how the values are set/modified as it may have direct impact to whom the access to presence 
data is given (as defined by the subscription authorisation policies). 

6.1 .1 Subscriber Presence Attributes and Values 

A subscriber is described by attributes: subscriber's status, communication means status, one or more communication 
address(es) (containing communication means and contact address), location (subscriber provided location and/or 
network provided location), priority, text. The attributes can be categorised as communication means and contact 
address specific information or generic information. Generic information attributes shall be: subscriber's status, location 
and text. Communication means and contact address specific information attributes shall be: communication means 
status, communication means, contact address, priority and text. 

- Generic information attributes, if these attributes are used as part of any tuple they shall use following values 
(values in parenthesis) to enable interoperability: 

- Subscriber's status (willing, willing with limitations, not willing, not disclosed), 

NOTE 1 : Attribute name subscriber's status has been defined in stage 1 and it does not imply any mapping to the 
IETF defined presence model e.g. IETF RFC 2778 [16], IETF RFC 2779 [17]. 

The subscriber's status attribute is not intended to be used when interworking with IM clients. Subscribers are 
able to provide more detailed willingness information as well as other information through the generic Text 
attribute, and the communication means and contact address specific Text attribute. 

- Location (e.g. Last known CGI/SAI and/or geographic co-ordinates and/or free format text and timestamp), 

- Text (free format text). 

- Communication means and contact address specific information attributes, if these attributes are used as part of 
any tuple they shall use following values (values in parenthesis) to enable interoperability: 

- communication means status (online, offline). 
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- communication means (Service type (e.g. telephony, SMS, email, multimedia messaging service, instant 
messaging service)), 

- contact address (E.164 (e.g. MSISDN), SIP URL, Email, Instant message address e.g. IM: name ©domain 
name), 

- Priority (Priority order for each of the defined communication means and contact address), 

- Text (free format text). 

NOTE 2: The mapping of these attributes and values to the IETF defined presence model IETF RFC 2778 [16], 
IETF RFC 2779 [17] may result one or several of the following: 

- using existing IETF defined attributes and values (or subset of them) 

- using existing IETF defined attributes but extending the value set 

- Creating new attributes to the tuples. 

The mapping of these values for tuples and different fields of the tuple is defined in stage 3. Furthermore, mechanisms 
to allow extensibility of the presence information in order to ensure interoperability are defined in stage 3. 

All these attributes shall be able to contain value NULL to enable polite blocking. 

6.1 .2 Presence Structure to Support Multiple Values for Attributes 

Attributes shall be mapped to separate tuples which have unique identifiers. If the presentity wants to show different 
presence information concerning one attribute to different watchers the presentity shall create more than one tuple that 
contain the same attribute with different value. The association of tuples to different watchers and watcher groups shall 
be based on the subscription authorisation policies. The presentity controls the value of the attribute by modifying the 
corresponding tuple. Figure 6.1.2-1 illustrates how different values for different watchers are provided utilising 
subscription authorisation policies. 

NOTE: The figure 6.1.2-1 is illustrative only and it shall not mandate or limit the server implementation options. 
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Figure 6.1.2-1 : Illustration how subscription authorisation lists are utilised to present different values 

of the same attribute to different watchers 



6.2 



Presence Information Model 



Presence information related to a particular communications means and contact address shall be carried in a presence 
tuple dedicated to that particular communications means and contact address. 
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Generic presence information that is not directly applicable to a particular communications means and contact address 
shall be conveyed in a way that conforms to the IETF presence model e.g. IETF RFC 2778 [16], IETF RFC 2779 [17] 
(to ensure interoperability) and preferably does not require multiple instances of this information to be sent. 

Generic information may be mapped to the tuples specific to each communication means and contact address. In that 
case the information shall be equal in each tuple. The stage 3 description should use a mechanism which conforms to 
the IETF presence model. 

Application identifiers may be allocated to applications, which are using presence capabilities. The conventions and the 
allocation mechanism for application identifiers are subject to stage 3 specification. Application identifier(s) are carried 
as part of the presence information. Application identifier(s) may be added to published presence information on the 
presentity side. In this case, the presence server shall include this application identifier to the relevant tuple(s) in the 
presence document together with the published information. On the watcher side the received application identifier may 
be used e.g. for determining which application should receive and process the related presence information. Details of 
processing the application identifier(s) on the Presence User Agent and watcher side are out of scope of this 
specification. 



Subscription authorisation policies 



Subscription authorisation policies shall define the watchers who can access the presence information of the presentity. 
In addition to the watcher identities, the subscription authorisation policies shall contain the presence information or 
reference to the presence information that is allowed to be accessed by the listed watchers. The subscription 
authorisation lists can be logically arranged to be part of the presence server or a separate entity in the network. 

In case of presence information fetch or subscription from a watcher that has not been authorised by the subscription 
authorisation policies, the presence server shall put the fetch or subscription on hold until the watcher has been 
authorised, added to the subscription authorisation lists or until a preconfigured timer has expired. 

Subscription authorisation lists can be divided into three different categories: personal subscription authorisation lists, 
public subscription authorisation lists and blocking subscription authorisation lists. 

Personal and general subscription authorisation lists shall define which watchers can access which information. 
Personal subscription authorisation lists shall explicitly identify watchers, while general subscription authorisation lists 
relate to groups of watchers whose exact identities are not necessarily known by the presentity e.g. "all watchers". 

Blocking subscription authorisation lists shall define watchers that are not allowed to access any presence information 
related to the presentity. 

A presentity shall be able to manage several personal and general subscription authorisation lists as well as blocldng 
subscription authorisation lists. 

The three subscription authorisation list categories shall be evaluated in the following order: blocking subscription 
authorisation lists, personal subscription authorisation lists and general subscription authorisation lists. 

The following shows an example where the presentity has defined a single subscription authorisation list for each 
category. 

In this particular example, once the hit is found the evaluation is halted and presence information according to access is 
delivered. 

1 . Is the watcher on the blocking subscription authorisation list? 

2. Is the watcher on the personal subscription authorisation list? 

3. Is the watcher on the general subscription authorisation list (created e.g. by service provider containing all 
watchers)? 

4. Send a notification to the presentity of pending subscription authorisation request. 



ETSI 



3GPP TS 23.141 version 10.0.0 Release 10 



24 



ETSI TS 123 141 VI 0.0.0 (2011-03) 



Presence 

subscription or 

fetch 




On block 
subscription 
authorisation list 


No ^ 


On personal 
subscription 
authorisation list 


No ^ 


On general 
subscription 
authorisation list 


No 


Possible notification or 
without notification to 
the presentity of pending 
subscription 




._^ — ^ 












Yes 

r 


Yes 


Yes 


^ 





No data available 



Access tuples 
related to that list 



Access tuples 
related to that list 



Figure 7-1 : Example of subscription authorisation list evaluation order for presence service 



8 Charging requirement 



The following charging requirement for presence service is identified. The requirements shall be realized by 
enhancements of the IMS charging mechanism as specified in TS 32.240 [6] and TS 32.260 [7]. 

1) Watcher Presence Proxy shall be able to provide the charging information for watcher requests per watcher for 
presence enquiry or subscription and subsequent notifications. 

2) Presentity Proxy shall be able to provide the charging information for updates to presence information per 
watcher. 

3) The Presence Server shall be able to provide the charging information for notifying the watcher of updates to 
presence information. Presence Server shall be able to provide the charging information for subscription to 
Watcher Lists and receiving notification of Watcher Information. Presence Server shall be able to provide the 
charging information for collecting the record of watcher list information per presentity. The Presence Server 
shall be able to provide the charging information for publishing presence information per presentity. 

4) Presence List Server shall be able to provide the charging information for Watcher subscription to Presence Lists 
and receiving notification of Presence Information. 

5) It shall be possible to apply specific tariffs (e.g. zero rating) to the bearer and/or signalling traffic associated with 
the above presence service "events". Differentiating in the IP Connectivity access network between the 
signalling traffic related to presence events and signalling traffic related to other IMS SIP communications is not 
a requirement. 
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Annex A (informative): 
Information flows 

A.1 General information flow 

Figure A. 1-1 illustrates the message flow for user A requesting presence information for user B in a different network. 
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Figure A.1-1 : Presence enquiry message flow 

1. The A party sends a presence enquiry to Watcher Application A (WA-A). The A party identifies B by B's 
address (e.g. MSISDN or URI). The enquiry can be of various types, e.g.: 

a) "tell me the current state of B" 

b) "tell me all state changes of user B for the next x hours" 

c) "tell me when B next changes state" 

d) "stop telling me about B" 

2. Watcher Application A 'authenticates' A and checks their credit status (details of authentication and credit status 
are outside scope of this message flow) 

3. Watcher Application A sends a "Presence enquiry for B" message to Watcher Presence Proxy. 

4. The Watcher Presence Proxy derives B's network name from B's address (details of how this is derived is outside 
the scope of this message flow). 

5. The Watcher Presence Proxy sends a "Presence enquiry for B" message to B's network's Presentity Presence 
Proxy. 

NOTE: Authentication may be necessary between A and B party networks in line with techniques used in other 
instances of inter operator message flow; precise details are outside the scope of this message flow. 

6. The Presentity Presence Proxy derives the address of B's Presence Server 

7. B's network Presentity Presence Proxy sends "Presence enquiry for B" message to B's Presence Server. 
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8. B's Presence Server processes the presence enquiry request (e.g. check A is one of B's buddy's and B still wants 
A to watch him/her). 

9. B's Presence Server raises charge record for A against A's network (precise details are for further study) 

10. B's Presence Server sends B's status back to Watcher Application A in Originating PLMN (may be returned via 
Presentity Presence Proxy and Watcher Presence Proxy). 

1 1. Watcher application returns B's presence to use A. 

NOTE 1: Steps 10 and 1 1 are repeated as necessary if B party has been requested to provide regular presence 
updates. 

NOTE 2: In the event that the presence enquiry message is "stop telling me about B" steps 8-11 are just an 
acknowledgement for watcher application A. 



A.2 Detailed information flows 
A.2.1 Overview of flows used 

The messages used in this clause are representative and are not meant to indicate any particular protocol as this is 
outside the scope of this document. In this clause the following messages have been used: 

SuhscrihePres: This is a request by a watcher to obtain presence information about a presentity. The message may 
be used to either request the current presence information or to subscribe to updates of presence 
information for a particular time period. This flow may also be used to un-subscribe to periodic 
updates. The request needs to convey the presence related events that that the watcher is be 
interested in. A presence server may accept or deny such a request. 

MsgAck: This is a generic message acknowledgement for the message flows. It may be used to indicate a 

positive or negative acknowledgement. In the latter case, the message may convey an indication 
for the rejection. 

Query: This message is used by a Presentity presence proxy to request the HSS/HLR to provide the 

necessary information to locate a presence server that is associated with a presentity. 

Resp: This message is the reply by the HSS/HLR to provide the required information to the Query 

message above. 

NotifyPresUp: This message is used to notify a watcher of updates to a presentitiy's presence information. The 
watcher would have either requested the current presence information or had previously 
subscribed to periodic updates. The message may contain the presence information or a pointer to 
the information. 

PresUpdateMsg: This message is used by a Presence user agent, the Network agent, and the External agent to 
provide the presentity' s presence information to the Presence Server. This message shall be 
capable of conveying the complete set of presence information associated with a presentity. This 
message shall also be capable of conveying a subset of the presence information associated with 
the presentity. to provide updates of a presentity's presence information to a presence server. This 
message needs to be able to convey the presence information associated with a presentity. The 
message may contain the presence information or a pointer to the information. (Note: there are 
similarities with the NotifyPreseUp message listed above since they both convey presence 
information. However for simplicity, different message names are used). 
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A.2.2 Flows demonstrating how watchers subscribe to presence 
event notification 

The clause covers the flows that show how watchers can request presence information about a presentity. 

A.2.2. 1 IMS Watcher and IMS Presentity in the same or different IM-CN 
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Figure A.2.2.1-1 : IMS Watcher registering for event notification 

Figure A.2.2.1-1 shows an IMS watcher subscribing to presence event notification about an IMS based presentity. The 
presentity may either be in the same IM-CN subsystem as the watcher or may be in a different IM-CN subsystem. The 
flows for both these cases are the same. 

Note-i: The path of the SUBSCRIBE dialog may optionally include additional I-CSCF(THIGs) in networks where 
network topology hiding is applied. 

Note-ii: The flow shows the case that the S-CSCF of the Presentity does not remain in the path of the dialog. 

The details of the flows as follows: 

1. A watcher agent in a UE wishes to watch a presentity's presence information, or certain parts of the presentity's 
presence information (defined by the filters included in SubscribePres). To initiate a subscription, the UE sends 
a SubscribePres message request containing the presence related events that it wishes to be notified of, together 
with an indication of the length of time this periodic subscription should last. The UE sends the SubscribePres 
information flow to the proxy (subscriber identity, home networks domain name). The SubscribePres may also 
include an indication of the watcher's capability to handle partial notifications. 

2. The P-CSCF remembers (from the registration process) the next hop CSCF for this UE. In this case the 
SubscribePres is forwarded to the S-CSCF in the home network. In this case, the P-CSCF and the S-CSCF act as 
a Watcher Presence Proxy. 

3. The S-CSCF is unable to resolve the presence server address of the presentity that the UE is requesting to watch, 
and as a result forwards the SubscribePres message to the an I-CSCF offering part of the Presentity Presence 
Proxy functionality. The S-CSCF shall examine the home domain of the presentity associated with the request 
and if the request is for a presentity outside the operator's domain, it determines the external I-CSCF. If the 
request is for a presentity in the same domain, the S-CSCF forwards the request to the local I-CSCF. 
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4. The I-CSCF examines the presentity identity and the home domain identity and employs the services of a name- 
address resolution mechanism to determine the HSS address to contact. The I-CSCF shall query the HSS to 
obtain the address of the S-CSCF associated with the Presentity. It shall query the HSS via a Query message. 

5. The Query Resp message from the HSS provides the name of the S-CSCF associated with the presentity. 

6. The I-CSCF, using name of the Presence Server shall determine the address of the S-CSCF through a name- 
address resolution mechanism. The SuhscrihePres message is forwarded to the S-CSCF. 

7. The S-CSCF using any necessary filtering criteria forwards the SubscrihePres message to the appropriate 
Presence Server. 

8. At this stage the presence server performs the necessary authorisation checks on the originator to ensure it is 
allowed to watch the presentity. Once all privacy conditions are met, the presence server issues a MsgAck to the 
S-CSCF. (In the case where the privacy/authorisation checks fail, then a negative acknowledgement is sent to the 
watcher). 

9. The S-CSCF forwards the to the I-CSCF. 

10. The I-CSCF forwards the MsgAck to the originating S-CSCF. 

1 1. The S-CSCF forwards the MsgAck message to the P-CSCF. 

12. The P-CSCF forwards the MsgAck to the watcher agent in the UE. 

13. As soon as the Presence Server sends a MsgAck to accept the subscription, it sends a NotifyPresUp message with 
the current full state of the presentity's tuples that the watcher has subscribed and been authorised to. The 
NotifyPresUp is sent along the path of the SUBSCRIBE dialog to the S-CSCF allocated to the Watcher. Further 
notifications sent by the Presence server may either contain the complete set of presence information, or only 
those tuples that have changed since the last notification if the watcher has indicated the capability to process 
partial notifications. 

NOTE: If charging for updates to presence information per watcher is enabled, then the presentity presence proxy 
will remain in the SUBSCRIBE dialogue path and the NotifyPresUp is routed through the presentity 
presence proxy. The presentity presence proxy (S-CSCF) will provide the charging update. 

14. The S-CSCF forwards the NotifyPresUp to the P-CSCF. 

15. The P-CSCF forwards the NotifyPresUp to the watcher application in the UE. 

16. The UE acknowledges the receipt of the NotifyPresUp message with a MsgAck sending this to the P-CSCF. 

17. The P-CSCF forwards the MsgAck message to the S-CSCF. 

18. The S-CSCF allocated to the presentity forwards the MsgAck to the Presence Server. 

A.2.3 Flows demonstrating how presentities update Presence 
Information 

A.2.3. 1 Updating presence information by terminals without support of the 
Pep reference point 

For the case of terminals that do not support the Pep reference point presence information can be provided alternative 
mechanisms such as SMS, WAP etc. The Presence User Agent provides the necessary interworking with the presence 
server. As previously indicated, the PUA may be located with network entities such as a WAP WML/HTTP server or 
SMS-C, however this is an implementation issue and outside of the scope of technical report. This particular example is 
illustrative and shows the case where a user updates presence information through a WAP browser, where the Presence 
User Agent is located inside the WAP WML/HTTP server and is illustrated in figure A.2.3. 1-1 below. It is 
acknowledged that other possibilities exist. 
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Figure A.2.3.1-1 : Updating presence information via WAP WML/HTTP server 

1 . The user opens a WAP session by requesting a WAP URL that is dedicated to updates of presence information. 

2. Using a WAP browser, the user modifies aspects of 'user presence information. 

3. The WML/HTML server, which in this example hosts the Presence User Agent (although the PUA may be a 
separate entity, in which case the interface to the PUA will be proprietary), sends a PresUpdateMsg to the 
Presence Server. Additional functionality may be required to locate the presence server associated by the 
presentity. In this particular example, it is assumed that the PUA is configured with the appropriate address of 
the presence server. 

4. The Presence Server acknowledges the PresUpdateMag with a MsgAck to the WAP WML/HTTP server. 

A.2.3.2 IMS Registration Notification process to the Presence Server within 
IMS 

The following flow describes how the presence server is notified of an IMS registration event by the network elements. 
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Figure A.2.3.2-1 : IMS Registration Notification procedure for the Presence Server 



ETSI 



3GPP TS 23.141 version 10.0.0 Release 10 



30 



ETSI TS 123 141 VI 0.0.0 (2011-03) 



1. UE registration takes place with the S-CSCF as detailed in TS 23.228 [9]. As part of this process, the filtering 
criteria are downloaded to the S-CSCF from the HSS. The filter criteria contains instructions that the registration 
be sent to the presence network agent (e.g. registration, de-registration). 

2. The S-CSCF sends the registration to the Presence Network Agent via the ISC interface. 

3. When the Presence Network Agent receives the notification of the IMS registration event from the S-CSCF, it 
determines that this registration is an event that the Presence Server is interested in and informs the Presence 
Sever. 

A.2.3.3 CS/PS Notification process of the Presence Server 

The following flow describes how the presence server is notified of an event by the network elements for a CS/PS 
subscriber. 
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Figure A.2.3.3-1 : CS/PS Notification procedure for tlie Presence Server 

1 . For network event to be reported on behalf of a CS/PS subscriber, the necessary triggers are armed in the 
MSC/SGSN. This takes place off-line and is outside the scope of this TS as to how it is achieved. 

2. At the occurrence of an event between the HLR and the MSC/SGSN, (e.g. UE detach) a notification message is 
generated. 

3. A MAP notification message (NOTE_MM_EVENT) is sent to the Network Agent via Pc/Pg interface on the 
occurrence of an event, details of this are outside the scope of this flow. There may be some address resolution 
needed by the network agent to locate the presence server but details of this is also outside the scope of this flow. 

4. The Network Agent informs the Presence Server. The Presence Server notifies all authorised watchers and sends 
an acknowledgement to the Network Agent. 

5. Network Agent sends an MM_Event_Ack to the MSC/SGSN. 
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A.2.3.4 Updating presence information by terminals with Pep interface 
support 
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Figure A.2.3.4-1 : Updating presence information via the Pep interface 

1. The PUA residing in the UE generates a PressUpdateMsg message which contains the new presence 
information. The means for the PUA to compose this presence information is outside the scope of this 
specification. 

2. P-CSCF forwards the message to the user's S-CSCF. 

3. S-CSCF forwards message to the correct Presence Server based on ISC filtering rules. 

4. Presence Server authorizes the presence update, and checks what information the message contains. The 
Presence Server then processes the updated presence information according to the client's request. The Presence 
Server sends a MsgAck response back to UE. 

5. S-CSCF forwards the response back to the P-CSCF 

6. P-CSCF forwards the response back to the UE. 
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A.2.4 Presence Server notifying watcher of updates to presence 
information 

A.2.4. 1 IMS based Watcher and presentity in the same or different IM-CN 
subsystem 
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Figure A.2.4.1-1 : Presence Server updating IMS watcher 

Figure A.2.4.1-1 shows how an IMS based watcher is notified of updates to a presentity's presence information. The 
flows are applicable to the case where the Watcher and Presentity are in the same or in different IM-CN subsystems. 

Note-i: The path of the SUBSCRIBE dialog (i.e. also the NOTIFY transaction) may optionally include additional 
I-CSCF(THIGs) in networks where network topology hiding is applied. 

Note-ii: The flow shows the case that the S-CSCF of the Presentity does not remain in the path of the dialog. 

Details of the flows are as follows: 

1 . The Presence Server determines which authorised watchers are entitled to receive the updates of the presence 
information for this presentity. For each appropriate watcher, the presence server sends a NotifyPresUp message 
that contains the full or partial updates to the presence information. This NotifyPresUp is sent along the path of 
the SUBSCRIBE dialog to the S-CSCF of the Watcher. 

2. The S-CSCF forwards the NotifyPresUp message to the P-CSCF of the watcher. 

3. The P-CSCF forwards the NotifyPresUp message to the UE. 

4. The UE acknowledges the NotifyPresUp message with a MsgAck to the P-CSCF. 

5. The P-CSCF forwards the MsgAck message to the S-CSCF. 

6. The S-CSCF of the Watcher forwards the MsgAck to the Presence Server. 
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A.2.5 Presence User Agent subscribing to watcher list and 
receiving notification of a new watcher subscription 
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Figure A.2.5-1 : Presence User Agent subscribing to watcher list and receiving notification of a new 

watcher subscription 

Figure A.2.5-1 shows a Presence User Agent subscribing to watcher Hst and receiving notification of a new watcher 
subscription that is not contained in the current subscription authorisation poHcies. The details of the flows are as 
follows: 

1) The Presence User Agent initiates a subscription to the Presence Server requesting notification of any new 
watcher subscriptions. 

2) The presence server issues a MsgAck to the Presence User Agent. 

3) A watcher wishes to watch the Presentity. To initiate a subscription, the watcher sends a SubscribePres message 
request containing the presence related events that it wishes to be notified of, together with an indication of the 
length of time this periodic subscription should last to the Watcher Presence Proxy. The Watcher Presence Proxy 
sends the SubscribePres information flow to the Presentity Presence Proxy. 

4) The SubscribePres is forwarded by the Presentity Presence Proxy to the Presence Server. 

5) The Presence Server checks the subscription authorisation policies and determines that this is a new watcher 
subscription not contained in the current subscription authorisation policies and so sends a notification to inform 
the Presence User Agent of the request from the new watcher. 

6) The presence server issues a MsgAck to inform the watcher that the Presence Server has received the watcher's 
request for Presence information. The MsgAck is sent to the Presentity Presence Proxy. 

7) The MsgAck is forwarded by the Presentity Presence Proxy to the watcher via the Watcher Presence Proxy. 

Steps 8-10 depend on the actions of the Principal. The Principal can ignore the notification sent in step 5 or can 
respond with an Update of the subscription authorisation policies to Accept, Accept with conditions or Deny the 
request. 

8) The Presence User Agent sends an UpdateSubscriptionAuthorisationPolicies to the Presence Server. (If the 
Presence User Agent decides to accept, block or accept with conditions the Presence Information requested by 
the watcher an appropriate SubscriptionAccepted, Sub scriptionBlo eked or SubscriptionAcceptedWithConditions 
is sent within the UpdateSubscriptionAuthorisationPolicies to the Presence Server). 
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9) If the UpdateSubscriptionAuthorisationPolicies accepts the subscription then the Presence Server sends a 

NotifyPresUp message with the current state of the Presence User Agent to the Presentity Presence Proxy. If the 
UpdateSuhscriptionAuthorisationPolicies indicates that the subscription is blocked then steps 9 and 10 are not 
performed. 

10) The Presentity Presence Proxy forwards the NotifyPresUp message to the watcher via the Watcher Presence 
Proxy. 
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